Вадим Миженский
Руководитель управления разработки цифровых продуктов
С помощью ESB подхода и Data Lake снижаем нагрузку на системы, исключаем потерю данных при обмене, упрощаем изменение IT-систем, ускоряем анализ всех данных.
Вы также получите
Таблицу сравнения
типов интеграций
При обмене “точка-точка” в момент отказа одной из систем данные могут теряться: одна система считает сообщение переданным, когда вторая его не получила.
Мы настраиваем интеграции так, что при обрыве связи сообщение считается необработанным и будет передано в следующем проходе.
При старом подходе источник отдает данные, как есть. Потребитель должен преобразовать их под свой формат. При такой схеме любое изменение в источнике повлечет каскад изменений всех связанных потоков данных.
Изменение ERP или любой другой системы не вызовет доработок всех связанных систем. Если система изменится, это затронет только коннекторы “источник-хранилище”. Для всех потребителей все останется без изменения.
Одни и те же данные нужны разным системам. Потребители дублируют запросы в систему-источник, что увеличивает нагрузку. Если в компании есть одна система для хранения основных данных, она будет получать огромное число запросов. Часто это старая монолитная система, которую в будущем бизнес хочет заменить.
Потребители обращаются в хранилище. Нагрузка на основной источник снижается без доработок самой системы и увеличения ресурсов. Когда придет время заменить старую систему на несколько новых сервисов, нужно будет изменить потоки “источник-хранилище”. Изменения не затронут множества потребителей.
Для подключения множества однотипных потребителей (например, розниц) часто создается API внутри системы. При этом нагрузка, которую создают потребители, ложится на эту систему. Недоступность системы-источника станет проблемой для всех потребителей. Они не смогут получить данные.
Мы создаем API-коннекторы не внутри сервиса, а отдельным сервисом. Они работают независимо от системы-источника и выдерживают высокую нагрузку. Вы сможете обслуживать системы без проблем для множества потребителей.
Чтобы передать объект с типом “ссылка”, нужно убедиться, что все справочники созданы в системе-потребителе. Иначе объект будет создан битым или поток выдаст ошибку.
Наши коннекторы проверяют, выполняется ли контракт системы (полнота, корректность).
Только когда все условия будут выполнены, сообщение отправится потребителю
Информация об объекте может храниться
в нескольких источниках. Нужно запросить информацию по каждому источнику и объединить для отправки.
Наше решение позволяет агрегировать данные объекта. Например, собирать “заказы”, “оплаты” отдельно (из разных источников) и передавать их, как “заказы с оплатами”.
Такая запись не регистрируется к обмену 1С. Система-получатель должна знать эту особенность 1С и самостоятельно вычислять изменения.
Наши коннекторы могут проверять удаление из табличной части. Если удаление было, помечают
в хранилище. Потребителям не нужно делать вычисления.
1С не предоставляет срез актуальных цен. Потребитель должен сам определить, какая цена из всего регистра (прошлые, настоящие, будущие) - актуальная.
Используя хранилище, мы вычисляем актуальные цены, чтобы их могла забрать любая система-потребитель без лишней логики.
Внедряя ESB, мы создаем общее структурированное хранилище данных предприятия: Data Warehouse (DWH).
К такому хранилищу легко подключить любую систему аналитики и выгрузки отчетов. Все данные уже готовы.
Строим архитектуру хранилища так, что формирование отчетов по большому массиву информации не снижает скорость ежедневного обмена данными.
Логируем ключевые этапы работы каждого потока. Если случится ошибка, которая требует реакции, вы получите сообщение в telegram. В нем будет описание ошибки и ссылка на подробности.
Вы сможете реагировать на инциденты проактивно, а не по обращениям пользователей. Оператор техподдержки точно будет знать, где и что пошло не по сценарию. Это поможет решить инцидент быстрее.
Мы развернем систему мониторинга с нуля. Либо настроим мониторинг в вашей инфраструктуре.
При нашем подходе в архитектуре нет единой точки отказа. Шина данных (ESB) - это набор микросервисов, не связанных между собой.
Компоненты ESB не зависят друг от друга и могут работать на разных серверах в разных локациях.
Отказ обмена любой из систем затрагивает только эту систему. Все остальное продолжает работать.
Мы уверены в своем подходе. Расскажите о проблеме, которую нужно решить. В документах мы укажем результат, который вы получите, стоимость и срок (обычно 1-2 месяца).
Если после реализации вы останетесь недовольны результатом, можете не подписывать акт и не оплачивать работы.
Мы используем Opensource решения, поэтому наши клиенты сокращают расходы на оплату лицензий без риска ограничений со стороны законодательства разных стран.
Мы оценили, как три популярных типа интеграций влияют на качество IT-контура. Результат представлен в компактной таблице сравнения. Отправьте заявку и получите файл бесплатно.
Калькулятор считает по точной, но упрощенной формуле. Состав работ по вашему проекту и конечная стоимость могут отличаться. Итоговый расчет сделает ваш персональный менеджер.
Калькулятор считает по точной, но упрощенной формуле. Состав работ по вашему проекту и конечная стоимость могут отличаться. Итоговый расчет сделает ваш персональный менеджер.
С вами свяжутся персональные менеджеры
Email:
Telegram: